Description

Roles

Attributes

Steps

1. Understand requirement details:

   Examine the relevant Use Cases and Supporting Requirements Specification to understand the scope of the design task and the expectations on the Design. Work with the Stakeholder and Analyst to clarify ambiguous or missing information.

    

   If the requirements are not represented in some sort of scenario form (for example a non-functional requirement might not have a scenario associated with it), a scenario will have to be identified that appropriately exercises the requirements under consideration.

    

   If the requirements are determined to be incomplete or incorrect, work with an analyst and stakeholder to get the requirements improved and possibly submit a change request against the requirements.

2. Understand the architecture:

   Review the Architecture Notebook to identify changes and additions to the architecture. Work with the architect if there is any uncertainty on the understanding of relevant parts of the architecture or of the conformance of the design strategy.

    

   This step can be skipped if there were no changes to the architecture in the previous iteration

3. Identify design elements:

   Identify the elements that collaborate together to provide the required behavior. This can start with the key abstractions identified in the Architecture Notebook, design, domain analysis, and classical analysis of the requirements (noun filtering) to derive the elements that would be required to fulfill them. The Entity-Control-Boundary Pattern provides a good start for identifying elements.

    

   Existing elements of the design should be examined to see if they should participate in the collaboration. It is a mistake to create all new elements in each execution of this task.

4. Determine how elements collaborate to realize the scenario:

   Walk through the scenario distributing responsibilities to the participating elements and ensuring that the elements have the relationships required to collaborate.

    

   These responsibilities can be simple statements of behavior assigned to elements; they need not be detailed operation specifications with parameters, etc. Similarly, the relationships can just be defined at this step. This step is about ensuring that a quality model is being created that is robust enough to support the requirements.

    

   Look to the Architecture Notebook and previous design work to create a consistent collaboration. Work with the architect to understand the details and motivations of the architecture. Look to reuse existing behavior and relations or to apply similar structure to simplify the design of the overall system.

5. Refine design decisions:

   Refine the design to an appropriate level of detail to drive implementation and to ensure that it fits into the architecture. In this step the design can take into consideration the actual implementation language and other technical decisions.

    

   Revisit the identification of the elements and the collaborations that realize the scenarios if necessary as this refinement takes into consideration details at a lower level of abstraction. Discuss testability issues, such as design elements that are difficult to test or critical performance areas, with the tester and architect.

    

   Evolve the design by examining recent changes in the larger context of the design and determine if refactoring and redesigning techniques will improve the robustness, flexibility, and understandability of the design.

    

   Incorporate Architectural Mechanisms from the architecture. Apply consistent structure of the elements and organization of the behavior as in other areas of the design and use patterns identified in the architecture.

6. Design internals (for large or complex elements):

   Design large or complex elements or some complex internal behavior in more detail. This might just involve devising an algorithm that could be performed to produce the desired behavior. Add additional operations, attributes, and relationships to support the expectations of an element.

    

   Design the state of the element over the course of its lifetime to ensure its proper behavior in various circumstances. It may be useful to describe a state machine for elements with complex states.

7. Communicate the Design:

   Communicate the system's design to those who need to understand it. Though this is described here toward the end of the task, communication should be going on throughout the steps. Working collaboratively is always better than reviewing the work after it is complete.

    

   Here are some ways to communicate the design:

   • Formal models specified in UML.
   • Informal diagrams that render static structure and capture dynamic behavior.
   • Annotated code that communicates information about the static structure. This can be supplemented with textual descriptions of collaborative behavior across code modules.
   • Data models to describe the database schema.

    

   Here are some examples of individuals who will need to understand the design of the system:

   • Developers who will implement a solution based on the design.
   • Architects who can review the design to ensure that it conforms to the architecture or who might examine the design for opportunities to improve the architecture.
   • Other designers who can examine the design for applicability to other parts of the system.
   • Developers or other designers who will be working on other parts of the system that will depend on the elements designed in this task.
   • Other reviewers who will review the design for quality and adherence to standards.

8. Evaluate the Design:

   Evaluate the object design for coupling, cohesion, and other quality design measurements.

    

   Consider the design from various angles to ensure that it is a high-quality, communicable design. Work with other technical team members; an independent party can provide a fresh perspective. Use the tester and architect to provide perspectives on design quality and adherence to the architecture. However, when identifying potential reviewers keep in mind that if someone can add value by reviewing the design, then perhaps they could have added even more value by actively participating in the design effort itself. If design flaws are identified, improve the design.

Inputs and Outputs

WorkProduct	Input	Output	Allowable States
Architecture Notebook			(none)
Design			(none)
Supporting Requirements Specification			(none)
Use Case			(none)

Other Instances

Instance Parent
Enterprise OpenUP (with CobiT)Elaboration Iteration [1..n]Develop the ArchitectureDevelop Solution Increment (Develop the Architecture)
Enterprise OpenUP (with CobiT)Elaboration Iteration [1..n]Develop Solution Increment (Elaboration Iteration [1..n])
Enterprise OpenUP (with CobiT)Transition Iteration [1..n]Develop Solution Increment (Transition Iteration [1..n])